Many computer graphic images are created by mathematically modeling the interaction of light with a three-dimensional (3D) scene from a given viewpoint. This process, called “rendering,” generates a two-dimensional (2D) image of the scene from the given viewpoint and is analogous to taking a photograph of a real-world scene.
As the demand for computer graphics, and in particular for real-time computer graphics, has increased, computer systems with graphics processing subsystems adapted to accelerate the rendering process have become widespread. In these computer systems, the rendering process is divided between a computer's general purpose central processing unit (CPU) and the graphics processing subsystem, architecturally centered about a graphics processing unit (GPU). Typically, the CPU performs high-level operations, such as determining the position, motion, and collision of objects in a given scene. From these high-level operations, the CPU generates a set of rendering commands and data defining the desired rendered image or images. For example, rendering commands and data can define scene geometry, lighting, shading, texturing, motion, and/or camera parameters for a scene. The graphics processing subsystem creates one or more rendered images from the set of rendering commands and data.
Scene geometry is typically represented by geometric primitives, such as points, lines, polygons (for example, triangles and quadrilaterals), and curved surfaces, defined by one or more 2D or 3D vertices. Each vertex may have additional scalar or vector attributes used to determine qualities such as the color, transparency, lighting, shading, and animation of the vertex and its associated geometric primitives.
Many graphics processing subsystems are highly programmable through an application programming interface (API), enabling complicated lighting and shading algorithms, among other things, to be implemented. To exploit this programmability, applications can include one or more graphics processing subsystem programs, which are executed by the graphics processing subsystem in parallel with a main program executed by the CPU. Although not confined merely to implementing shading and lighting algorithms, these graphics processing subsystem programs are often referred to as “shading programs,” “programmable shaders,” or simply “shaders.”
A variety of shading programs are directed at modeling illumination in a scene. The physical plausibility of rendered illumination often depends on the application, more specifically, whether or not the rendering is done in real-time. Physically plausible illumination at real-time frame rates is often achieved using approximations. For example, ambient occlusion is a popular approximation because of its high speed and simple implementation. Another example is directional occlusion. Many algorithms can only approximate direct illumination, which is light coming directly from a light source.
Certain algorithms compute indirect illumination coming from different directions for every pixel on the screen. Computing indirect illumination for every pixel is expensive. One such algorithm is voxel cone tracing (see, Crassin, et al., “Interactive Indirect Illumination Using Voxel Cone Tracing,” Proc. of Pacific Graphics, Vol. 30 (2011), No. 7, incorporated herein by reference). To improve performance, it is possible to use sparse tracing. For example, indirect illumination may be computed for every fourth pixel on the screen (referred to as “traced pixels”) by tracing outgoing radiance of nearby geometry stored in volumetric data structures. Indirect illumination for the remaining pixels (referred to as “untraced pixels”) may then be interpolated, for example using a bilateral filter that considers pixel depth and normals.